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Problem  Studied 


The  proposed  research  was  to  develop  a  data  structure  definition  facility 
(DSDF)  and  an  access  control  facility  suitable  for  inclusion  in  high-level 
programming  languages.  The  research  v.is  not  intended  to  include  the  design  of 
a  complete  language  but  instead  involved  the  development  of  programming 
language  features  that  aid  in  the  development  of  languages  designed  for  pro¬ 
ducing  reliable  software. 

The  DSDF  was  to  be  capable  of  specifying  and  implementing  a  wide  variety 
of  views  of  data.  The  intentions  were  to  develop  a  facility  capable  of  defining 
real  world  data  objects  as  well  as  system-oriented  data  objects.  In  addition, 
the  DSDF  was  to  merge  the  language  view  of  real  world  and  system  data  objects. 

Results  of  the  Research 

To  meet  the  objectives  of  this  research,  an  encapsulation  mechanism,  the 
module,  was  designed  for  specifying  and  implementing  abstract  data  types  (or 
data  objects)  in  high-level  programming  languages.  The  format  of  the  module  is 
illustrated  in  Figure  1;  it  is  similar  in  some  respects  to  other  encapsulation 
mechanisms  such  as  the  cluster  in  CLU  [31.  Parameterized  types  are  permitted 
within  the  module  context  and  restrictions  to  them,  if  any,  can  be  specified. 

The  rights  specification  is  an  explicit  specification  of  the  rights  to  objects 
of  the  type  being  defined. 

The  logical  structure  (LS)  component  of  a  module  specification  essentially 
characterizes  a  data  object  by  defining  restrictions  to  relationships.  An  LS, 
by  itself,  does  not  specify  a  data  type;  instead,  it  highlights  features  of  a 
data  type  and  communicates  them  to  the  user  and  to  the  implementer  of  the  type. 
To  some  extent,  a  logical  structure  specifies  what  an  object  looks  like,  (inde¬ 
pendent  of  any  representation).  In  general,  a  logical  structure  component  of  a 
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nodule  nodulejname  (^parameters,  if  any>3 
restrictions  to  parameters 

rights 

logical  structure 

lsname 

objects 

attributes 

relationships 


invariant  assertions 

semantics  of  operations 

constructive 

nonconstructive 

♦ 

representation 

implementation 

end  module_name 

Figure  1.  Format  of  a  module 

module  can  contain  multiple  logical  structure  specifications,  each  one  named 
(using  lsname  in  Figure  1)  and  giving  a  different  view  of  the  data  type.  Normally-, 
however,  only  one  logical  structure  specification  is  given  per  data  type. 


The  semantics  of  operations  can  be  specified  in  three  ways:  (1)  by  using 


the  constructive  approach  described  in  this  paper  and  in  Claybrook,  et  al.  Cl], 

(2)  by  using  Guttag's  axioms  [21  (only  one  logical  structure  specification  is 
meaningful  in  this  case),  or  (3)  by  using  both  the  constructive  approach  and 
Guttag's  axioms.  The  representation  and  implementation  specifications  are  self- 
explanatory. 

The  Logical  Structure 

Basically,  the  logical  structure  of  a  data  object  is  characterized  by 
specifying  relationships  between  constituent  object  types  and  by  defining  re¬ 
strictions  to  relationships.  Each  LS  specified  in  the  logical  structure  component 
of  a  module  is  given  a  name  such  as  CTREE  in  the  genealogy  tree  data  type 
specified  in  Figure  2.  A  logical  structure  specification  can  then  be  referred 
to  by  this  name.  The  name(s)  of  the  component  object  types  are  given  in  the 
objects  section.  The  attributes  of  each  component  object  are  given  in  the 
attributes  section;  they  are  given  in  the  form  of  a  function  from  objects  to  values. 
The  relationship  names  and  the  object  type(s)  involved  in  a  relationship  are 
given  in  the  relationships  section.  The  relationships  are  binary  relationships 
and  are  specified  in  functional  form. 


module  genealogy  tree 

rights  add_person,  add_child 

logical  structure 
l3name  CTREE 
objects  PERSONS 

attributes  NAME :  PERSONS  t£  string 

DOB:  PERSONS  £o  integer 

relationships 

CHILDOF :  PERSONS  to  PERSONS 

PARENTOF:  PERSONS  to  PERSONS  REDUNDANT 

NEXTALPHA:  PERSONS  to  PERSONS  REDUNDANT 

NEXTOLDEST:  PERSONS  to  PERSONS  REDUNDANT 


Figure  2.  A  genealogy  tree  data  type. 
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invariant  assertions 

Vx.y:  PERSONS 

1.  If  x  CHILDOF  y  then  DOB(x)  >  DOB(y) 

2.  if  x  4  y  then  NAME(x)  4  NAME(y) 

3.  CHILDOF  has  indegree  at  most  2 

A.  CHILDOF  is  acyclic 

5.  x  CHILDOF  y  i£f  y  PARENTOF  x 

6.  NEXT ALPHA  Is  ordered  on  NAM  and  is  linear 

7 .  NEXTOLDEST  is^  ordered  on  DOB  and  is  linear 

semantics  of  operations 

OCCUR  -  occurrence  <P:  collection  PERSONS,  N :  collection  NAME, 

D:  collection  DOB,  CO:  CHILDOF,  PO:  PARENTOF,  NO:  NEXTOLDEST, 
NA:  NEXTALPHA> 

operations  wrt  GTREE 

add_j)erson  (OCCUR,  NEWNAME,  SOMEDOB)  -  if  NEWNAME  €  {N(n)|n  e  p} 
then  ERROR  else  <P',  N’,  D',  CO,  PO,  NO’,  NA'>  * 
where  x:  PERSONS  and  x  i  P 
P'  -  P  u{x} 

N'  «  N  u(<x,  NEWNAME> } 

D'  -  D  u{<x,  SOMEDOB>) 

end  add_person 

add_child  (OCCUR,  NEWNAME,  SOMEDOB ,  PARENT_N Af IE  1 ,  PARENT  NAME 2)  * 
if  NEWNAME  €  (N(n)  |n  e  P)  or  P ARENT_NAME 1  t  (N(n)  J  n  €  P} 
or  PARENT _NAM£2  {  (N(n)  n  e  P} 
or  D(PARENT_NAME1)  >  SOMEDOB 
or  D(PARENT_NAME2)  >  SOMEDOB  then  ERROR 

else  <P'.  N',  D',  CO*,  PO',  NO*,  NA'> 
where  newnode:  PERSONS  and  newnode  i  P 

x  e  P  l  PARENT_NAME1  -  N(x) 
y  €  P  5  PARENT_NAME2  *  N(y) 

P '  ■  P  u {newnode} 

N'  "  Nu{<nevmode,  NEWNAME> } 

D'  =  Du{<newnode,  SOMEDOB>} 

CO'  ■  CO u  {<newnode,  x> ,  < newnode,  y>} 

PO'  ■  POu(<x,  newnode> ,  <y,  nevmode>} 

end  add  child 


end  genealogy-tree 


Figure  2.  (Continued) 


*In  both  the  add_j>erson  and  add_child  operations  in  Figure  2,  we  indicate  that 
the  redundant  relations  NO  and  NA  are  actually  affected,  even  though  the  operation 
definitions  do  not  explicitly  show  this. 


The  most  important  ingredient  of  a  logical  structure  is  the  invariant 
assertion.  The  primary  function  of  the  invariant  assertion  is  to  specify  res¬ 
trictions  to  each  of  the  relationships  named  in  the  relationships  section.  In 


addition,  invariant  assertions  can  also  specify  relationships  between  relations 
(see  the  genealogy  tree  data  type  example  in  Figure  2  for  the  relationship  between 
the  CH1LD0F  and  PARENTOF  relations) .  The  relationships  section  and  the  invariant 
assertions  section  permit  the  specifier  of  a  data  type  to  communicate  to  both  the 
user  and  the  implenenter  of  the  data  type  what  he  considers  to  be  the  type's  most 
important  aspects. 

The  invariant  assertions  have  at  least  two  important  uses.  First,  and  per¬ 
haps  most  importantly,  they  specify  what  Taylor  [4J  refers  to  as  the  "meaning"  of 
a  relationship.  For  instance,  the  is-part-of  and  is-spouse-of  relationships  are 
syntactically  equivalent  but  have  much  different  occurrence  structures.  Secondly, 
the  invariant  assertions  can  be  used  directly  or  indirectly  to  provide  a  defini¬ 
tive  test  for  valid  versus  invalid  occurrence  structures  when  operations  are 
applied. 

The  syntax  for  the  assertions  is  given  in  Appendix  A  along  with  a  catalog 
of  properties  for  relations.  Many  of  these  properties  are  defined  using  first- 
order  predicate  calculus  notation.  Using  names  to  describe  properties  makes  the 
Invariant  assertions  easier  to  read,  write  and  specify. 

Semantics  of  Operations 

Previously,  we  said  that  the  semantics  of  operations  can  be  specified  in 
three  distinct  ways:  (1)  by  using  the  constructive  approach  described  in  this 
paper,  (2)  by  using  Guttag's  axioms,  or  (3)  by  using  both  the  constructive 
approach  and  Guttag's  axioms. 

The  operations  (constructive  approach)  are  defined  in  terms  of  how  they 
affect  an  occurrence  of  the  data  object  being  specified.  An  occurrence  of  a 
data  type  is  represented  as  a  tuple  of  elements  such  as  OCCUR  in  Figure  2.  In 
general,  the  elements  in  a  tuple  consist  of  collections  of  instances  of  all 
object  types,  collections  of  all  attribute  values,  and  all  relations.  For 
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ex ample,  In  Figure  2,  P  is  a  collection  of  PERSONS,  N  is  a  collection  of  NAME'S, 
D  is  a  collection  of  DOB's,  and  CO,  PO,  NO,  and  NA  are  the  four  relations 
restricted  by  the  invariant  assertions  of  the  LS  named  CTREE.  An  operation 
definition,  then,  consists  of  specifying  how  the  operation  affects  each  of  the 
elements  in  the  occurrence  tuple.  Not  all  operations  make  changes  to  an  occur¬ 
rence,  nor  do  all  operations  affect  all  elements  in  an  occurrence  tuple.  For 
example,  a  find-children  operation  (not  specified)  for  the  genealogy  tree  data 
type  does  not  affect  an  occurrence,  and  the  add  person  operation  shown  in  Figure 
2  does  not  change  the  CHILDOF  or  PARENTOF  relations. 

Figure  3  illustrates  the  stack  data  type,  specified  using  the  principal 
investigator's  constructive  approach  and  Guttag's  nonconstructive  approach. 
Redundant  specification  appears  to  be  useful  because  Guttag's  axioms  are  useful 
for  verifying  that  an  implementation  is  correct  and  the  constructive  specifica¬ 
tion  is  useful  as  an  aid  to  both  the  user  and  the  implementer  of  the  type. 

The  utility  of  redundant  specification  is  a  topic  of  future  research. 


module  stack 

rights  top,  pop,  push 

logical  structure 
lsname  STK 
objects  NODE 

attributes  VALUE:  NODE  to  string 
relationships  ONTOPOF:  NODE  to  NODE 
invariant  assertions 

1 .  ONTOPOP  is  linear 

semantics  of  operations 

OCCUR  ■  occurrence  <N:  collection  NODE,  V:  collection  VALUE, 
0 :  ONTOPOF> 


Figure  3*  stack  data  type  specified  (partially 
specified)  using  both  Claybrook's 
constructive  approach  and  Guttag's 
nonconstructive  approach 
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1 

} 


operations  wrt  STK 
constructive 

emptystackO  -  <0,  0,  0  > 

push  (OCCUR,  NEWVALUE)  -  <N\  V’,  0’> 

where  for  x:  NODE  and  x  i  N  and  a  e  N  a  (Jy  e  N) (<y,  a  >  e  0) 
N'  -  N  u  {x} 

V1  -  V  u  (<x,  NEWVALUE> } 

O'  *  i£  OCCUR  =  emptystackO  then  0 
else  0  u  (<x,  a>} 

end  push 

pop  (OCCUR)  -  i£  OCCUR  ■  emptystackO  then  ERROR 
else  <N ' ,  V' ,  0’> 

where  for  x:  NODE,  x  c  N  and  ( JJ  a  e  N)  (<a,  x  >  e  0) 

N'  -  N  -  (x) 

V'  «  V  -  { <x »  V(x)>} 

O'  -  0  -  {<x,  a>  |  <x,  a  >c0) 

end  pop 

top  (OCCUR)  *  _if  OCCUR  “  emptystackO  then  ERROR 

else  V(x) ,  where  x  e  N  and  ( jj  y  e  N)  (<  y ,  x  >  e  0) 

end  top 

nonconstructive 

declare  stk:  stack;  elm:  Integer 
pop (NEWSTACK)  -  NEWSTACK 
pop(push(stk,  elm))  •  stk 
top (NEWSTACK)  -  ERROR 
top(push(stk,  elm))  ■  elm 

end  stack 


Figure  3.  (Continued) 


Redundant  Relations 

A  relation  is  classified  as  redundant  if  it  can  be  totally  specified  in 
terms  of  the  attributes  and  non-redundant  relations.  Intuitively,  a  redundant 
relation  does  not  provide  any  new  information;  it  merely  highlights  a  particular 
aspect  of  the  logical  structure.  NEXTALPHA,  NEXTOLDEST  and  PARENTOF  relations 
are  redundant  in  the  genealogy  tree  logical  structure  (see  Figure  2).  CHILDOF 
is  not  redundant  since  it  provides  new  information  which  cannot  be  obtained  from 
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the  attributes.  Note  that  since  CHILDOF  and  PARENTOF  are  almost  interchangeable, 
one  could  have  chosen  CHILDOF  as  the  redundant  relation  and  PARENTOF  as  the  non- 

redundant  relation.  Non-redundant  relations  must  be  included  in  each  operation 
definition,  whereas  redundant  relations  need  not  be  included  in  the  operation 
definition.  In  some  cases,  the  specifier  may  choose  to  define  how  an  operation 
actually  affects  a  relation,  even  though  the  relation  is  redundant.  This  approach 
assures  the  implementer  of  all  changes  that  an  operation  makes  to  all  relations. 
Including  redundant  relations. 

Summary  of  Results 

The  significant  accomplishments  of  the  year's  research  efforts  include: 

1)  the  specification  of  the  module  encapsulation  mechanism  as  a  means 
for  specifying  and  implementing  abstract  data  types, 

2)  the  development  of  the  logical  structure  component  of  the  module, 
in  particular  the  invariant  assertions,  for  specifying  restrictions 
to  relationships  between  constituent  object  types,  and 

3)  the  development  of  the  notation  for  specifying  the  semantics  of 
operations  (using  the  constructive  approach  to  specification). 

The  combination  of  these  three  things  provide  the  basis  for  a  number  of  further 
research  topics,  including  verifying  the  correctness  of  implementations  of 
abstract  data  types.  * 

*This  is  one  of  the  objectives  of  the  renewal  year  of  this  grant. 
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Appendlx  A 

This  appendix  specifies  the  syntax  for  invariant  assertions  and  presents 
a  catalog  of  names  that  are  used  to  expedite  and  facilitate  the  specification 
of  Invariant  assertions. 

An  assertion  is  of  the  form: 

<Relation  name>  <noise  words>  <property> 

ON  <object  set> 

or  assertion  in  first-order  predicate  calculus  augmented  by  standard  set 
notations  involving  the  named  objects,  attributes,  and  relationships, 

Notes 

<Relation  name>  is  any  relation  named  in  the  relationships  section  of  the  LS. 
cnoise  words>  may  be  added  for  readability, 

<property>  may  have  embedded  parameters  and  are  defined  in  the  following  catalog. 
ON  <object>  is  optional.  <object>  is  the  name  of  a  set  of  objects  named  in 
the  objects  section  of  the  LS. 

The  default  value  is  the  set  of  objects  on  which  relation  is  defined. 

In  the  following  catalog,  R  stands  for  the  relation  parameter  and  A  stands 
for  the  object  set  parameter.  Embedded  parameters  are  underlined, 
noloops  (Va:A) (not  aRa) . 

nocycles  (Va:A)(Vn: integer) (rfb^,  b£,  . bn:A) 

(aRb,  and  b,Rb.  and  ...  and  b  Ra  and  a^b  and  nil). 

1  x  z  n 

acyclic  R  has  noloops  and  R  has  nocycles. 

Indegree  n  (Va:A) ( indegree ( a) »n) .* 
outdegree  n  (Va:A) (outdegree(a)-n)  .* 

Indegree  at  most  n  (Va:A) (indegree (a) Sn) .* 


n- 


oucdegree  at  most  n  (Va :A) (outdegree (a) £n) .* 

n:m  correspondence  R  has  indegree  at  most  n  and  R  has  outdegree  at  most  m. 

reflexive  (Va:A)(aRa) 

symmetric  (Va:A)  (Vb:A)  (aRb  iff  bRa) . 

anti-symmetric  (Va,b:A)(aRb  and  bRa  implies  a-b) . 

transitive  (Va,b,c :A) (if  aRb  and  bRc  then  aRc) . 

partition  R  is  reflexive,  symmetric  and  transitive. 

partially  ordered  R  is  reflexive,  anti-symmetric  and  transitive. 

totally  ordered  R  is  partially  ordered  and  (Va,b:A)(aRb  or  bRa). 

linear  R  is  acyclic  with  (card(A)sl  or  (3aeA)  (indegree  (a)  ■* 

0  and  outdegree  (a)*l  and  (3b cA) (indegree  (b)**l  and 
outdegree  (b)=0  and  (Vc:A)(if  cfa  and  cf*b  then 
indegree  (c)  ■  outdegree  (c)“l.) 

ordered  on  x  R  is  linear  and  (Va,b:A)  (aRb  implies  x(a)  <  x(b)). 
tree  A»0  or  (3a :A) (indegree  (a)=0  and  (Vb:A)(if  a?*b  then  indegree  (b)=l)) 
and  R  is  acyclic. 

pair  (3a,b:A) (A={a,b)  and  R  *  {<a,b>}). 

star  (3a:A) (indegree(a)«0  and  (Vb:A)  (if  a^b  then  indegree  (b)*l  and 
outdegree  (b)*0) . 

set  of  Y  (yP)(if  PcA  and  (Vx:P)  QfaiA)  (a  f  p  and  (aRx  or  xRa))  then 
R^P  is  Y  on  P) . 
forest  R  is  a  set  of  tree, 

pairs  R  is  a  set  of  pair, 

stars  R  is  a  set  of  star. 


*indegree  (a)  ■  cardfbjaRb)  and  outdegree  (a )  ■  card  (b|bRa). 
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